Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9608/000005_owner-urn-ietf _Mon Aug 5 00:02:46 1996.msg

Internet Message Format | 1997-02-19 | 9KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA05222 for urn-ietf-out; Mon, 5 Aug 1996 00:02:46 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA05215 for <[e-mail]>; Mon, 5 Aug 1996 00:02:41 -0400
Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA14348  (mail destined for [e-mail]); Mon, 5 Aug 96 00:02:38 -0400
Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa20264;
          5 Aug 96 0:02 EDT
Received: by skadhwe.lcs.mit.edu; (5.65/1.1.8.2/15Aug95-0306PM)
    id AA00929; Mon, 5 Aug 1996 00:02:20 -0400
Date: Mon, 5 Aug 1996 00:02:20 -0400
Message-Id: <[e-mail]>
From: Lewis Girod <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]> (message from Terry
    Allen on Sat, 3 Aug 1996 11:09:48 PDT)
Subject: Re: [URN] re NAPTR, URN-res-req
Sender: [e-mail]
Precedence: bulk
Reply-To: Lewis Girod <[e-mail]>
Errors-To: [e-mail]

On Sat, 3 Aug 1996 11:09:48 PDT, Terry Allen <[e-mail]> wrote:

>Would you sketch a sample lookup sequence for a URN for which official
>and unofficial hints have been injected into the system?  Is it a matter
>of user/client preferences as to which hints are heeded?  (See the
>Bobsnamespace example below.)

It would be a matter of end client preferences which hints would be
used first and which would be provided to the user at all.  I envision
the client requesting the official information as well as at most N
unofficial hints from the system for any particular URN lookup.  The
browser would use the official hint info by default while at the same
time pointing out that other information is available.  There might be
other types of preferences as well, I haven't thought about it too
much.

>I am imagining something like this:  Bobsnamespace consists of the
>names 1 through 8.  Bob sells off from this name space 2, 4, 5, and 7,
>rather than a block of names, and further he declines to resolve them
>after he sells them (maybe he goes out of business).  The result
>will be (I think) that no one resolver handles the entire name space,
>and that it is not possible to predict from the URN which of the
>several resolvers for Bobsnamespace should be queried first.

This is at the crux of the namespace migration problem.  The
generalized scheme I mentioned in the document involves two different
methods of delegation.  When Bob ``sells off'' names from his space,
he has the option of ``officially'' delegating the names or of
handling the delegation himself.  The difference here is that an
``official'' delegation puts the delegation information up at the
``top'' level, in effect flattening the namespace, at least in terms
of layers of resolution mechanism.  For Bob's clients, this has
advantages: (1) Bob has nothing to do with their resolution, because
their URNs go direct to their specified resolution service, so they
are not dependent on him, only on the top level (2) Depending on how
the top level resolution system works, this may be faster since it may
involve fewer steps of resolution.  The disadvantages to official
delegation are (1) a little bit more of the structure of your
namespace is publicly known (2) the top level gets big as time goes on
(but for this to work at all the system has to be able to scale in
response!) (3) it will likely cost money to enter an official
delegation, which is likely passed on to the client.

In answer to Bob's conundrum, if the names are not easily generalized
according to whatever rules exist (for example, simple string prefixes
after a canonicalization process) it will cost a lot more to
officially delegate the names, because in some cases there may simply
be no generalization and official delegation would be commensurate
with listing each URN.  To the degree that the names are not
officially delegated all bets are off when Bob goes out of business.
Presumably, however, Bob or someone else could extort sufficient funds
from of his clients to continue resolving the URNs.. ;-)

In general, with such a system clients who intend to use their URNs
for a long time would be wise to be sure that if something goes wrong
with their service providers they can salvage their URNs in a
cost-effective manner.

>This will work for some, perhaps a great many, URN lookups, but not
>all.

Yes.  Some URN lookups may want to use a secret or proprietary
resolution process for example.  No generalized system would be
sufficient in all such cases

>Further, it won't be possible to prevent people from inventing name
>spaces that don't decompose nicely.  The top-level URN name space
>registry can't refuse to register such name spaces, or it ceases to
>be useful.  In addition to grandfathering, there's a requirement to
>be able to "cousin-in" name spaces invented by people who weren't
>aware they weren't following the rules preferred by the top-level
>registry.  These may have to be resolved by brute force (matching
>the entire URN string) or use of other info.

This is true; but if a certain type of service is provided by this
system, it increases the likelihood that new namespaces fit themselves
into it.  To the degree that they don't or can't, they will need to be
escaped to other systems from the top level.  I guess it is a question
of balancing the goal of keeping URNs alive with that of having a
buildable system.  The system I sketched in section 4 and the NAPTR
proposal represent different points on this spectrum.  With any
system, there may be cases where a namespace is a real mess and can't
be effectively split up; either it gets served in total by someone
else or by some other technique, or parts of it are forced into the
system and the remaining parts are lost.

What we are really talking about here is having a dependable top level
sevice, one that doesn't go out of business as we suspect Bob might.
Presumably this dependability would stem from some kind of cooperative
management in which a large number of interested parties run servers
that serve a large distributed database.  This database can escape to
other similar systems if the need arises (or a new version of the
software can be written which extends the capabilities for
generalization exhibited by the original.)  The controversy is over
what basic services should be provided by this top level, and what
services should be delegated to other (possibly less dependable)
levels, and how this in fact affects the goals of long-lived URNs, of
flexibility of namespace design, and of grandfathering in existing
namespaces.

Personally, I think that one simple way to fix a lot of these problems
is to offer each person his/her own namespace (for a very reasonable
fee), in a way that can be generalized so that their URNs are easily
mapped to the resolution service of their choice.  For example,
URN:PEOPLE:unambiguous_name/* would be one syntax (perhaps it would be
best to assign people numbers in order to cut down on lawsuits and
trademark issues).  Doing this guarantees a certain base level of
stability, since people currently tend to keep a constant identity for
say 50 years or so.  Doing this adds a lot of stuff to the database
initially, but the total amount is limited by other factors such as
the availability of food and the asking price for slots in the
database, so scaling issues should be controllable.  How each person
chooses to structure his namespace below this is not specified, but at
least any damage is constrained to that individual's personal space.

This sort of fix would occur after the system is in place (i.e. the
future), and I bring it up mostly as an example of the sorts of
namespace-design techniques that will likely help with these problems,
after the top level system is implemented and the framework is
essentially set in stone, at least for the short term.  I doubt that
any system can keep every URN alive, unless it is prepared to store
the whole list of URNs.  What is more important is getting most of
them (this includes deciding what meaning of ``most'' satisfies you),
and providing ways of setting things up that both satisfy the clients'
requirements and ensure that their URNs will stick around.  Those that
choose not to follow these guidelines may get into trouble.  I think
this is true of any system that works on a principle of generalizing
classes of URNs; for all systems, there is some generalization
strategy is not efficient (for example, if all of your URNs are
products of two large prime numbers... ;-) )


  Regards,

     Lewis